Scope Types in C
Randy Yates
In general, there are three scopes with which a variable in C
can possess:
1. the variable can be seen by any function in the entire program;
2. the variable can be seen by any function in one particular file.
3. the variable can be seen by one particular function.
Are there any names that these three scopes are conventionally given?
--
%% Randy Yates
%% DSP Engineer
%% Ericsson / Research Triangle Park, NC, USA
%% Work: randy...@ericsson.com, 919-472-1124 Home: ya...@ieee.org
Richard Heathfield
<3741AA6F...@ericsson.com>...
> Hi,
>
> In general, there are three scopes with which a variable in C
> can possess:
>
> 1. the variable can be seen by any function in the entire program;
> 2. the variable can be seen by any function in one particular file.
> 3. the variable can be seen by one particular function.
>
> Are there any names that these three scopes are conventionally given?
Number 2 is, strictly speaking, incorrect. ITYM 'translation unit' rather
than 'file'.
And you missed "4. the variable can be seen only within a local scope
(within a function)."
Here are the names I give them:
1. evil muthah, must be hounded down and destroyed until deader than dead.
2. fairly evil muthah, must be put up with until a better way can be found.
3. local variable.
4. local scope variable.
Here are slightly more common terms:
1. global variable, extern(al) variable, variable with external linkage.
2. global variable (incorrect but common usage), file scope variable.
3. local variable, auto(matic) variable (but note that function-scoped
statics also fall into category 3 and should not be described as auto).
4. local scope variable, block variable.
I don't know whether any of these names are defined by the Standard - I am
just citing the conventions I have encountered in the industry. Further
info from the - er - ANSI Gang welcomed. :-)
HTH
--
Richard Heathfield
The bug stops here.
Randy Yates
>
> Randy Yates <randy...@ericsson.com> wrote in article
> <3741AA6F...@ericsson.com>...
> > Hi,
> >
> > In general, there are three scopes with which a variable in C
> > can possess:
> >
> > 1. the variable can be seen by any function in the entire program;
> > 2. the variable can be seen by any function in one particular file.
> > 3. the variable can be seen by one particular function.
> >
> > Are there any names that these three scopes are conventionally given?
>
> Number 2 is, strictly speaking, incorrect. ITYM
Would you please spell out your words? What does ITYM mean?
> 'translation unit' rather
> than 'file'.
> And you missed "4. the variable can be seen only within a local scope
> (within a function)."
I see no difference between this and 3. I meant to say:
3. the variable can be seen by *only* one particular function.
Richard Heathfield
int main(void)
{
int can_be_seen_throughout_main;
{
int can_only_be_seen_between_here_and_the_star;
/* * */
}
return 0;
Eric Amick
> Richard Heathfield wrote:
>>
>> Randy Yates <randy...@ericsson.com> wrote in article
>> <3741AA6F...@ericsson.com>...
>> > Hi,
>> >
>> > In general, there are three scopes with which a variable in C
>> > can possess:
>> >
>> > 1. the variable can be seen by any function in the entire program;
>> > 2. the variable can be seen by any function in one particular file.
>> > 3. the variable can be seen by one particular function.
>> >
>> > Are there any names that these three scopes are conventionally given?
>>
>> Number 2 is, strictly speaking, incorrect. ITYM
> Would you please spell out your words? What does ITYM mean?
>> 'translation unit' rather
>> than 'file'.
>> And you missed "4. the variable can be seen only within a local scope
>> (within a function)."
> I see no difference between this and 3. I meant to say:
> 3. the variable can be seen by *only* one particular function.
He's talking about something like
if (x == y)
{
int foo;
/* etc. etc. */
}
The variable foo is visible only within that block, not in the entire
function.
--
Eric Amick
Columbia, MD
eam...@clark.net
Kaz Kylheku
wrote:
>Hi,
>
>In general, there are three scopes with which a variable in C
>can possess:
>
> 1. the variable can be seen by any function in the entire program;
> 2. the variable can be seen by any function in one particular file.
> 3. the variable can be seen by one particular function.
Wrong. The ANSI C standard defines the following scopes.
Ordinary identifiers and structure/union/enum tags can exist at file scope, or
block scope. File scope extends until the end of the translation unit.
Block scope ends with the enclosing block.
Only statement labels have function scope.
There is no such thing as ``program'' scope. You are confusing scope
with linkage. Linkage is the mechanism by which names are resolved to
static objects and functions. Occurences of a name with external linkage refer
to the same object or function program-wide. Occurences of name with internal
linkage refer to the same entity only if they appear in the same translation
unit.
Scope has nothing to do with linkage. A name with block scope can have
external linkage. For example:
#include <stddef.h>
int foo(void)
{
extern void *malloc(size_t);
/*...*/
}
Here, the identifier malloc is declared with block scope. It is not visible
after the closing brace of the enclosing block. Yet it is an external name
that refers to a function that isn't defined in the same translation unit.
In C, scope is purely a lexical notion that has to do with the placement of a
declaration relative to other program text. Linkage is more of a semantic
notion that has to do with the meaning of a declaration.
Lawrence Kirby
randy...@ericsson.com "Randy Yates" writes:
>Hi,
>
>In general, there are three scopes with which a variable in C
>can possess:
>
> 1. the variable can be seen by any function in the entire program;
This isn't a matter of scope but of linkage. Scope does not relate to a
variable but to the declaration of a variable. Scope is always limited to
the translation unit in which a declaration appears (i.e. a declaration
is obly visible within its translation unit). Linkage allows different
declarations to refer to the same object or function. External linkage
allows (but does not require) linked declarations to be in different
translation units.
> 2. the variable can be seen by any function in one particular file.
The is file scope. Note that it can only be seen by code after the
point at which the declaration occurs, not necessarily by any function.
> 3. the variable can be seen by one particular function.
There is a scope called function scope but that applies *only* to goto
labels. What I believe you are referring to here is "block scope"
where an identifier is visible only in the compound statement (i.e. {}
enclosed block of code) that is is declared in. Note therefore that an
identifier with block scope is not necessarily visible throughout a
function.
>Are there any names that these three scopes are conventionally given?
There are in fact 4 scopes:
1. File scope
2. Function scope (for goto labels)
3. Block scope
4. Function prototype scope
The last is perhaps not obvious until you see it. Consider a function
declaration
void foo(int arg1, double arg2);
The identifiers arg1 and arg2 have function prototype scope and are not
visible outside the declaration. They are visible inside it so you
can't, for example, write
void foo(int arg1, double arg1);
since the uses of the name arg1 clash. The corresponding definition
of foo() could be
void foo(int iarg, double darg)
{
printf("%d %f\n", iarg, darg);
}
Things to note here that iarg and darg are (obviously) different identifiers
to arg1 and arg2. Since their scopes are different this doesn't matter.
Also iarg and darg have block scope due to being in a function
definition rather than a declaration. If they had function prototype scope
they wouldn't be visible in the fucntion body. This is an oddity however
since they are defined outside the block they are considered to be
part of.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Martin Ambuhl
>
> Hi,
>
> In general, there are three scopes with which a variable in C
> can possess:
>
> 1. the variable can be seen by any function in the entire program;
>
C has 4 kinds of scope (not 3), and one of your three is not a scope at all.
They are defined by the standard.
[1. is not a question of scope but of linkage. This is external linkage. There
are also identifiers with internal linkage and no linkage.]
2. file scope
3. function scope - applies only to label names.
4. block scope
5. function prototype scope.
--
Martin Ambuhl (mam...@earthlink.net)
Note: mam...@tiac.net will soon be inactive
Will Rose
: Hi,
: In general, there are three scopes with which a variable in C
: can possess:
: 1. the variable can be seen by any function in the entire program;
There is no such scope; you probably mean external linkage.
: 2. the variable can be seen by any function in one particular file.
File scope.
: 3. the variable can be seen by one particular function.
You probably want block scope, but there is in fact a function scope
which applies to labels. There's also a prototype scope, which applies,
strangely enough, to arguments in function prototypes.
Randy Yates
>
> On Tue, 18 May 1999 13:59:11 -0400, Randy Yates <randy...@ericsson.com>
> wrote:
> >Hi,
> >
> >In general, there are three scopes with which a variable in C
> >can possess:
> >
> > 1. the variable can be seen by any function in the entire program;
>
>
> Ordinary identifiers and structure/union/enum tags can exist at file scope, or
> block scope. File scope extends until the end of the translation unit.
> Block scope ends with the enclosing block.
>
> Only statement labels have function scope.
>
> There is no such thing as ``program'' scope. You are confusing scope
> with linkage. Linkage is the mechanism by which names are resolved to
> static objects and functions. Occurences of a name with external linkage refer
> to the same object or function program-wide. Occurences of name with internal
> linkage refer to the same entity only if they appear in the same translation
> unit.
>
> Scope has nothing to do with linkage. A name with block scope can have
> external linkage. For example:
>
> #include <stddef.h>
>
> int foo(void)
> {
> extern void *malloc(size_t);
>
> /*...*/
> }
>
> Here, the identifier malloc is declared with block scope. It is not visible
> after the closing brace of the enclosing block. Yet it is an external name
> that refers to a function that isn't defined in the same translation unit.
>
> In C, scope is purely a lexical notion that has to do with the placement of a
> declaration relative to other program text. Linkage is more of a semantic
> notion that has to do with the meaning of a declaration.
scope
(1) ...
(2) In programming, the visibility of variables within a
program; for example, whether one function can use a
variable created in another function.
Are you really trying to help or are you simply flexing your knowledge to make
yourself look good? All your definitions and terms, while in some instances may
be very important, are obscuring the issue here, I believe. For instance, I
don't see how scope and linkage can be separated since they both deal with
the "visibility of variables within a program."
I posted the original question because we have decided in our code reviews that
all input and output variables which a function uses should be documented in the function's
header, and that the "scope" of that variable, i.e., whether the variable is visible to
all functions or only to functions in a file (sorry, I'm not going to use your pet phrase
"translation unit"), should also be specified. Hence I was simply asking what terms are
conventionally used to delineate this seemingly common situation.
It was suggested that both of these types of variables are considered "global" and thus
should be delineated with another scoping adjective like "global file scope" and
"global program scope". Not only do I disagree with the use of the term "global" for
"file scope" variables, but this also seems to be needlessly complex. I have always seen,
and I believe the colloquial meaning of the word itself implies, that "global" variables
are those visible to all functions in a program.
I have tentatively decided on something like this:
/******************************************************************************
NAME
WBDVoiceChannelCalculatePhaseError
PARAMETERS
Scope Input/Output Type Name
----- ------------ ---- ----
global input INT32 aVariableName
file input S_15 wbdBuffer
file input UINT16 wbdBufferIndex
file output S_15 phaseErrorPerBit
file input/output S_15 phaseErrorPerSample
parameter output INT16* filteredErrorPtr
RETURN
none
DESCRIPTION
A function description.
AUTHOR
Randy Yates
******************************************************************************/
It may not be conventional, but it is simple, concise, and precise.
To those of you who would argue against the mere existence of "global"
variables, take it to another thread and stop answering questions I
didn't ask.
Jens Schweikhardt
# Kaz Kylheku wrote:
#>
#> On Tue, 18 May 1999 13:59:11 -0400, Randy Yates <randy...@ericsson.com>
#> wrote:
#> >Hi,
#> >
#> >In general, there are three scopes with which a variable in C
#> >can possess:
#> >
#> > 1. the variable can be seen by any function in the entire program;
#> > 2. the variable can be seen by any function in one particular file.
#> > 3. the variable can be seen by one particular function.
#>
#> Wrong. The ANSI C standard defines the following scopes.
#>
#> Ordinary identifiers and structure/union/enum tags can exist at file scope, or
#> block scope. File scope extends until the end of the translation unit.
#> Block scope ends with the enclosing block.
#>
#> Only statement labels have function scope.
#>
#> There is no such thing as ``program'' scope. You are confusing scope
#> with linkage. Linkage is the mechanism by which names are resolved to
#> static objects and functions. Occurences of a name with external linkage refer
#> to the same object or function program-wide. Occurences of name with internal
#> linkage refer to the same entity only if they appear in the same translation
#> unit.
#>
#> Scope has nothing to do with linkage. A name with block scope can have
#> external linkage. For example:
#>
#> #include <stddef.h>
#>
#> int foo(void)
#> {
#> extern void *malloc(size_t);
#>
#> /*...*/
#> }
#>
#> Here, the identifier malloc is declared with block scope. It is not visible
#> after the closing brace of the enclosing block. Yet it is an external name
#> that refers to a function that isn't defined in the same translation unit.
#>
#> In C, scope is purely a lexical notion that has to do with the placement of a
#> declaration relative to other program text. Linkage is more of a semantic
#> notion that has to do with the meaning of a declaration.
# scope
# (1) ...
# (2) In programming, the visibility of variables within a
# program; for example, whether one function can use a
# variable created in another function.
ISO 9899:1990 6.1.2.1 Scope of identifiers
An identifier is visible (i.e. can be used) only within a region of
program or text called its /scope/. There are four kinds of scopes:
function, file, block and prototype. [...]
# Are you really trying to help or are you simply flexing your knowledge to make
# yourself look good?
Kaz is trying to give a precise answer to your question.
# All your definitions and terms, while in some instances may
# be very important, are obscuring the issue here, I believe.
I understood Kaz very good. One needs to know C terminology though.
# For instance, I
# don't see how scope and linkage can be separated since they both deal with
# the "visibility of variables within a program."
Please understand that they are different concepts. Scope determines
where an identifier in one translation can be used (i.e. written to
refer to some entity). The difference of scope and linkage is obvious
for identifiers that don't *have* linkage (like labels, automatic
variables, structure tags, macro names etc). External and internal
Linkage only applies to functions and sometimes objects.
# I posted the original question because we have decided in our code reviews that
# all input and output variables which a function uses should be documented in the function's
# header, and that the "scope" of that variable, i.e., whether the variable is visible to
# all functions or only to functions in a file (sorry, I'm not going to use your pet phrase
# "translation unit"), should also be specified. Hence I was simply asking what terms are
# conventionally used to delineate this seemingly common situation.
Why do you refuse to communicate using terms defined as precise as
possible in an international standard, like "translation unit"? This
strikes me as uhm, ignorant. You seem to have only a vague idea of the
concepts of scope and linkage, so you should actually be thankful for
Kaz to weed out some misconceptions of yours.
# It was suggested that both of these types of variables are considered "global" and thus
# should be delineated with another scoping adjective like "global file scope" and
# "global program scope". Not only do I disagree with the use of the term "global" for
# "file scope" variables, but this also seems to be needlessly complex. I have always seen,
# and I believe the colloquial meaning of the word itself implies, that "global" variables
# are those visible to all functions in a program.
What is a global variable? There's no such thing in C. Consider this:
#include <stdio.h>
void foo (void);
int main (void)
{
foo();
return 0;
}
int bar = 0;
void foo(void)
{
printf ("%d\n", bar);
}
bar is an identifier with file scope and external linkage. But you can't
use it in main(), because scope begins with bar's declaration and *not*
with the start of the (yes!) translation unit. You can refer to bar from
any other translation unit by means of external linkage.
Keep in mind that comp.lang.c is one of the usenet newsgroups where
accuracy is highly valued and inaccuracies, however minor they may be,
are commented. I expect someone will also nit pick my article here. If
so, I will say "thanks for correcting me." Yes, I'm known for being
outright wrong sometimes or slighly inaccurate. Let's hope it's only
the latter this time :-)
PS: Ugh, your line length is > 76.
Regards,
Jens
--
Jens Schweikhardt http://www.shuttle.de/schweikh/
SIGSIG -- signature too long (core dumped)
Randy Yates
In the following code,
#include <stdio.h>
void foo (void);
int main (void)
{
foo();
return 0;
}
static int bar = 0;
void foo(void)
{
printf ("%d\n", bar);
}
"bar" WILL NOT be visible to functions in other files. However, in
#include <stdio.h>
void foo (void);
int main (void)
{
foo();
return 0;
}
int bar = 0;
void foo(void)
{
printf ("%d\n", bar);
}
"bar" WILL be visible to functions in other files.
Since the only difference is what you call linkage, then linkage
affects visibility and therefore scope.
> Scope determines
> where an identifier in one translation can be used (i.e. written to
> refer to some entity).
Where is this definition of scope found? Perhaps this is the entire
problem, i.e., there are multiple definitions of scope. In my mind,
scope refers to the visibility of variables.
Even if scope is defined the way you say, I still have the
problem I outlined previously, i.e., how does one distinguish
between variables that are visible only within a file and
those visible to the entire program? What syntax would you
use for these distinctions?
> The difference of scope and linkage is obvious
> for identifiers that don't *have* linkage (like labels, automatic
> variables, structure tags, macro names etc). External and internal
> Linkage only applies to functions and sometimes objects.
What's an object? As far as I know, there are no objects in C.
> Why do you refuse to communicate using terms defined as precise as
> possible in an international standard, like "translation unit"?
What's imprecise about "file?" When is a file not a translation unit?
We can call files
"operating-system specific persistent information storage units"
too, but while not use the simple 4-letter word "file?"
My problem is that I am a thinking man, and if you want me to speak
in terms that are more complex, you must demonstrate for me a good
reason. I have this attitude because I have seen many, many instances
where a problem or situation was made intractable because of
unnecessary complexity, thus I abhor it.
> What is a global variable? There's no such thing in C.
Thanks for the laugh, Jens! I'll now go proclaim to my colleagues that there's
this nut on usenet who thinks there's no such thing as global variables in
C. Ha!
Richard Stamp
>
>Are you really trying to help or are you simply flexing your knowledge to
These are not necessarily incompatible.
>All your definitions and terms, while in some instances may
>be very important, are obscuring the issue here, I believe.
Huh? Your question was specifically about the conventional terminology,
which has been pretty comprehensively explained to you. If you'd clarified
the situation in the first place like you have below, then you might have
got an answer closer to what you're looking for.
>For instance, I
>don't see how scope and linkage can be separated since they both deal
>with the "visibility of variables within a program."
If it were possible for the scope of an identifier to extend outside one
source file (or translation unit, if we must), then you wouldn't need to
include a separate declaration for the variable in other files which used
it. Being in scope would mean it was already "visible" there.
As you know, this isn't the case -- you have to declare the identifier
again, and then linkage plugs the two together.
The difference is important, in that it directly affects what (if anything)
you have to do to gain access to a particular variable. It's just that
you're experienced enough not to notice this any more.
[...]
>whether the variable is visible to
>all functions or only to functions in a file (sorry, I'm not
>going to use your pet phrase
>"translation unit"), should also be specified. Hence I was simply
>asking what terms are
>conventionally used to delineate this seemingly common situation.
There is certainly some confusion among C programmers between variables
which are only accessible in one file and those which are accessible in all
files (I'm not going to debate exactly what "accessible" means -- you all
know what I'm talking about). This manifests itself in the terms people
use, e.g. I've heard "global" used to mean both of these.
For your purposes I suggest you just make up some words and stick to them.
Program, file, and function would be possible and hopefully uncontroversial
choices.
>Not only do I disagree with the use of the term "global" for
>"file scope" variables, but this also seems to be needlessly complex.
>I have always seen,
>and I believe the colloquial meaning of the word itself implies, that
>"global" variables are those visible to all functions in a program.
Since there's disagreement over what "global" means it may be easiest --
both politically and technically -- to avoid using it. If you insist on
having the word "global" somewhere then I'm afraid you'll have to argue the
point with your colleagues. We can't offer anything concrete to back up
either point of view.
Kaz Kylheku
wrote:
>In the following code,
>
>
>
>#include <stdio.h>
>void foo (void);
>
>int main (void)
>{
> foo();
> return 0;
>}
>
>static int bar = 0;
>
>void foo(void)
>{
> printf ("%d\n", bar);
>}
>
>
>
>"bar" WILL NOT be visible to functions in other files. However, in
>
>
>
>#include <stdio.h>
>void foo (void);
>
>int main (void)
>{
> foo();
> return 0;
>}
>
>int bar = 0;
>
>void foo(void)
>{
> printf ("%d\n", bar);
>}
>
>
>
>"bar" WILL be visible to functions in other files.
>
>Since the only difference is what you call linkage, then linkage
>affects visibility and therefore scope.
Scope in the everyday dictionary sense, not scope in the ANSI C sense. The
scope of ``bar'' ends at the end of the above translation unit.
Another translation unit could repeat the declaration
extern int bar;
thereby introducing ``bar'' into its own scope. This identifier now refers to
the same entity as the same identifier in the other translation unit. This is
due to external linkage.
>> Scope determines
>> where an identifier in one translation can be used (i.e. written to
>> refer to some entity).
>
>Where is this definition of scope found? Perhaps this is the entire
>problem, i.e., there are multiple definitions of scope. In my mind,
>scope refers to the visibility of variables.
Scope merely determines the validity of the use of an identifier. When you use
an identifier, a declaration of it must be ``in scope'' (with one little
exception that will probably disappear from the language). It is purely a
lexical notion. In compiler terms, scope affects how a compiler structures its
internal symbol table data structures so that it can validate the uses of
identifiers, and resolve certain ambiguities (like when an identifier in an
inner block has the same spelling as one in an outer block or file scope).
Linkage is deeper. What it does is make *separately* declared identifiers in
*different* scopes, possibly in different translation units, refer to the same
entity. In compiler terms, linkage affects the nature of symbol information
deposited in object files; typically a separate linker tool will be able to
resolve the references according to their linkage. External linkage means, in
actual C implementations, that object files may export symbols, and may
contain unresolved references to symbols elsewhere. By this stage of
the program build, scope is just a distant memory.
>Even if scope is defined the way you say, I still have the
>problem I outlined previously, i.e., how does one distinguish
>between variables that are visible only within a file and
>those visible to the entire program? What syntax would you
>use for these distinctions?
External versus internal.
>> The difference of scope and linkage is obvious
>> for identifiers that don't *have* linkage (like labels, automatic
>> variables, structure tags, macro names etc). External and internal
>> Linkage only applies to functions and sometimes objects.
>
>What's an object? As far as I know, there are no objects in C.
There are data objects in C. C defines object as simply being a region of
storage which holds values and is made up of individually addressable bytes, et
cetera. This is consistent with conventional terminology. ``Object'' doesn't
always mean ``instance of a class type in an object-oriented language''. For
example, a file handle or socket are often called ``system objects''.
>> Why do you refuse to communicate using terms defined as precise as
>> possible in an international standard, like "translation unit"?
>
>What's imprecise about "file?" When is a file not a translation unit?
When the #include directive is used within it.
A translation unit is everything that is presented for translation: the base
source file plus any included materials, minus text skipped by conditional
preprocessing.
>We can call files
>"operating-system specific persistent information storage units"
>too, but while not use the simple 4-letter word "file?"
That would be reasonable, but if you then used ``file'' to refer to the
information assembled from multiple persistent information storage units, it
would not be consistent with the definition.
>Thanks for the laugh, Jens! I'll now go proclaim to my colleagues that there's
>this nut on usenet who thinks there's no such thing as global variables in
>C. Ha!
There is no such *term* as ``global variable'' in C, and people who use it tend
to be ignorant of the subtleties of linkage, duration and scope. Not to
mention that they are unfamiliar with the documents that define the tools they
are using, which is just plain bad engineering.
Lawrence Kirby
randy...@ericsson.com "Randy Yates" writes:
>Jens Schweikhardt wrote:
...
>> # All your definitions and terms, while in some instances may
>> # be very important, are obscuring the issue here, I believe.
>>
>> I understood Kaz very good. One needs to know C terminology though.
>>
>> # For instance, I
>> # don't see how scope and linkage can be separated since they both deal with
>> # the "visibility of variables within a program."
>>
>> Please understand that they are different concepts.
>
>
>
>In the following code,
>
>
>
>#include <stdio.h>
>void foo (void);
>
>int main (void)
>{
> foo();
> return 0;
>}
>
>static int bar = 0;
>
>void foo(void)
>{
> printf ("%d\n", bar);
>}
>
>
>
>"bar" WILL NOT be visible to functions in other files. However, in
What perhaps you don't understand is that visibility is not a property
of objects but of identifiers in source code. Specifically you make an
identifier visible by declaring it. The visibility extends from the
point of declaration to the point where the scope of that declaration ends.
In your example the identifier foo is visible from the ; of its declaration
right up to the end of the translation unit. Similarly bar is visible from
the ; at the end of its declaration (*). So bar is visible within foo() but
not within main(). None of these declarations are visible outside the
current translation unit. Note also that by including <stdio.h> you make
a lot of other identifiers visible, e.g. printf which you use in the
program.
* - strictly scope starts from the end of the declarator so in
int a, b;
the scope of a starts from the , not the ;
>#include <stdio.h>
>void foo (void);
>
>int main (void)
>{
> foo();
> return 0;
>}
>
>int bar = 0;
>
>void foo(void)
>{
> printf ("%d\n", bar);
>}
>
>
>
>"bar" WILL be visible to functions in other files.
No. This definition is only visible in this translation unit. However
it is possible to write
extern int bar;
in another translation unit and of course that declaration will be
visible in its own translation unit. By the process of linkage that
declaration is in some sense attached to the definition in the original
code such that both refer to the same object. Linkage is simply that:
making two different declarations refer to the same object or function.
C has 3 forms of linkage: external, internal and none. External seems
to be the most obvious but consider internal linkage. Internal linkage
causes two declarations of the same identifier in the *same* translation
unit to refer to the same object or function. E.g.
static void foo(void);
...
static void foo(void)
{
}
Here is a declaration and definition of a function and through the
mechanism of internal linkage they refer to the same function in the
execution environment. Here's an example you may not be familiar with:
#include <stdio.h>
static int a = 1;
int main(void)
{
int a = 2;
{
extern int a;
printf("%d\n", a);
}
return 0;
}
What will this program output? The answer is 1. There are 3 declarations
of a here (two of them also being definitions). The first is at file scope
and has internal linkage due to being declared static. The second is
an automatic variable at block scope and has no linkage (which means this
declaration can never refer to the same object as any other declaration).
The 3rd declaration of a is odd at first sight. It appears to be declaring
a with external linkage. However in this case it isn't. What extern actually
means for linkage purposes is "use the linkage of any previous declaration
of this identifier at file scope or default to external linkage if there
is none". Since there is a previous declaration of a at file scope this
declataion takes on the same linkage which is internal linkage.
Those are the gory details but don't worry too much about them right now,
the important thing is simply that the first and third declarations of a
both have internal linkage and are in the same translation unit. That
means that they refer to the same object. What I'm hoping to demonstrate
is that there is something fundamentally different between scope and
linkage.
scope: the region in a translation unit where a declaration is visible (*).
linkage: the process by which two separate declarations are made to refer
to the same object or function.
* - this is slightly complicated because declarations can be hidden by inner
declarations as the example above shows. The initial static definition
if a is hidden in the body of main by the automatic definition of a
which creates a completely separate variable. That in turn is hidden
by the inner extern declaration. The only declaration/definition of a
that the printf call can see is that inner one. However it is by the
process of linkage that it is able to use this to refer to the
object created by the first static definition.
>Since the only difference is what you call linkage, then linkage
>affects visibility and therefore scope.
I suppose the terms could have been defined in such a way to make that
statement true but the simple fact is that they aren't. I suppose we
could invent a new term, say, "accessibility" to describe a sort of
combined scope/linkage property but this is not what visibility or scope
alone describe.
>> Scope determines
>> where an identifier in one translation can be used (i.e. written to
>> refer to some entity).
>
>Where is this definition of scope found? Perhaps this is the entire
>problem, i.e., there are multiple definitions of scope. In my mind,
>scope refers to the visibility of variables.
That is a good starting point. You may be disappointed to know however
that the term "variable" has no well-defined meaning in C (see below)
>Even if scope is defined the way you say, I still have the
>problem I outlined previously, i.e., how does one distinguish
>between variables that are visible only within a file and
>those visible to the entire program? What syntax would you
>use for these distinctions?
Accessibility (by name) outside the current translation unit can only
occur through external linkage. So external linkage is probably the
termm you are looking for. "Global variables" is sometimes used as a loose
term for this but it is loose and not everybody understandard the same
thing by it.
>> The difference of scope and linkage is obvious
>> for identifiers that don't *have* linkage (like labels, automatic
>> variables, structure tags, macro names etc). External and internal
>> Linkage only applies to functions and sometimes objects.
>
>What's an object? As far as I know, there are no objects in C.
Objects are a fundamental part of C. They don't have the baggage of a
language like C++. This is how the C standard defines an object:
"3.14 object: A region of data storage in the execution envvironment, the
contents of which can represent values. Except for bit-fields, objects are
composed of contiguous sequence of one or more bytes, the number, order, and
encoding of which are either explicitly specified or implementation-defined
When referenced, an object may be interpreted as having a particular type."
So an object is closely related to a variable - it is the part of the
varaible what data is actually stored. It is more fundamental though,
an object doesn't inherently have as corresponding name, objects
created with malloc don't for example. And of course objects can be accessed
though pointers. Declarations are a way of associating a name with an
object that can be used to refer to that object in the local translation
unit. Defintions in addition actually cause an object to be created. e.g.
int a;
This creates an int object which we can refer to using the name a
extern int a;
This allows an object defined with the name a elsewhere in the program
to be referred to in this part of the program also using the name a.
>> Why do you refuse to communicate using terms defined as precise as
>> possible in an international standard, like "translation unit"?
>
>What's imprecise about "file?" When is a file not a translation unit?
A translation unit is what you get after you've processed #include directives
which may effectively import code from other files, and #if, #ifdef etc.
directives which may in effect remove code. The resulting translation
unit may end up very different to what is to be found in any single file.
>My problem is that I am a thinking man, and if you want me to speak
>in terms that are more complex, you must demonstrate for me a good
>reason. I have this attitude because I have seen many, many instances
>where a problem or situation was made intractable because of
>unnecessary complexity, thus I abhor it.
Well, look back at my definitions of scope and linkage. I don't think
they are unreasonably complex (even if the gory details of the language
are).
>> What is a global variable? There's no such thing in C.
>
>Thanks for the laugh, Jens! I'll now go proclaim to my colleagues that there's
>this nut on usenet who thinks there's no such thing as global variables in
>C. Ha!
Strictly there aren't. As noted above the term "global" has no official
meaning in C. I wonder if your colleagues are entirely clear on what they
mean by it. "External linkage" on the other hand is a precisely defined
term.
Randy Yates
>
> On Wed, 19 May 1999 10:37:53 -0400, Randy Yates <randy...@ericsson.com>
> wrote:
>
> >this nut on usenet who thinks there's no such thing as global variables in
> >C. Ha!
>
> to be ignorant of the subtleties of linkage, duration and scope. Not to
> mention that they are unfamiliar with the documents that define the tools they
> are using, which is just plain bad engineering.
If a rogue software engineer had a gun to your head and said "tell
me what a 'global C variable' is or I'll shoot," would you so arrogantly
dismiss the usage as well? I'd bet some good money you wouldn't.
You like to sit in your ivory computer science towers and criticize
those who ask for help without offering any real assistance.
Some of you are somewhat helpful, but for the most part I have
experienced arrogance here. That is sad because it means that
I will look elsewhere for my answers. Thank you, and have a
nice day!
Lawrence Kirby
randy...@ericsson.com "Randy Yates" writes:
>Kaz Kylheku wrote:
>>
>> On Wed, 19 May 1999 10:37:53 -0400, Randy Yates <randy...@ericsson.com>
>> wrote:
>>
>> >Thanks for the laugh, Jens! I'll now go proclaim to my colleagues that
> there's
>> >this nut on usenet who thinks there's no such thing as global variables in
>> >C. Ha!
>>
>> There is no such *term* as ``global variable'' in C, and people who use it
> tend
>> to be ignorant of the subtleties of linkage, duration and scope. Not to
>> mention that they are unfamiliar with the documents that define the tools they>> are using, which is just plain bad engineering.
>
>If a rogue software engineer had a gun to your head and said "tell
>me what a 'global C variable' is or I'll shoot," would you so arrogantly
>dismiss the usage as well? I'd bet some good money you wouldn't.
I'd be tempted to say in that situation "a global variable is whatever you
want it to be". It wouldn't be too far from the truth either. :-)
Of course truth in such situations isn't generally the main issue.
>You like to sit in your ivory computer science towers and criticize
>those who ask for help without offering any real assistance.
>Some of you are somewhat helpful, but for the most part I have
>experienced arrogance here. That is sad because it means that
>I will look elsewhere for my answers. Thank you, and have a
>nice day!
That's a shame because I believe here you are getting answers and
accurate ones at that. As for "ivory tower" I don't think there is any
real excuse for a professional C programmer not to be familiar with the
standard itself. Especially as a reference for the standard library
it can't really be beaten (although books like Plauger give a wider range
of information). My copy of "The annotated C standard" is certainly
the tattiest book I have. :-)
Noone Really
> #include <stdio.h>
>
> static int a = 1;
>
> int main(void)
> {
> int a = 2;
>
> {
> extern int a;
>
> printf("%d\n", a);
> }
>
> return 0;
> }
>
> What will this program output? The answer is 1. There are 3 declarations
> of a here (two of them also being definitions). The first is at file scope
> and has internal linkage due to being declared static. The second is
> an automatic variable at block scope and has no linkage (which means this
> declaration can never refer to the same object as any other declaration).
> The 3rd declaration of a is odd at first sight. It appears to be declaring
> a with external linkage. However in this case it isn't. What extern actually
> means for linkage purposes is "use the linkage of any previous declaration
> of this identifier at file scope or default to external linkage if there
> is none". Since there is a previous declaration of a at file scope this
> declataion takes on the same linkage which is internal linkage.
No. This is undefined behaviour. According to the standard as
originally written, the file scope declaration had to be visible. TC 1
changed it so that file scope was no longer required: the visible
declaration had to have internal or external linkage.
In this case, the visible declaration has no linkage, so extern *does*
mean external linkage. As a lexically identical identifier is used with
both internal and external linkage in the same translation unit,
undefined behaviour ensues.
Incidentally, this example shows that scope and visibility are not the
same thing: we are almost always within the scope of the identifier a
with internal linkage, but it is visible almost nowhere.
The way I usually explain these things is by starting off with:
namespace categorizes identifiers.
scope and visibility are properties of declarations of identifiers
linkage is property of identifiers
duration is property of objects
There are four namespaces: labels, tags, members and ordinary
identifiers. The concept of scope and visibility apply to labels, tags
and ordinary identifiers.
(Note that namespace means something different in C++).
Every declaration introduces into a scope the identifiers (or statement
labels) it declares: and these scopes can be of different natures. It
could be (1) file scope, (2) parameter scope (3) block scope or (4)
function scope; and the only things that can be put into the last are
statement labels. Scope, except for function scope begins at the end of
the declarator (or tag name or enumerator) and ends at the end of the
file, parameter list, block or function as appropriate. The usage
`identifiers a and b have the same scope' is never meant literally
(because their scopes start at the end of their respective declarators:
they can not start at the same point), but rather is used to indicate
that the scopes end at the end of the same file, parameter list, block
or function. (Note that a struct or union definition does *not*
introduce a scope, but the parameter list in a function prototype
non-definition declaration *does*.)
An identifier is visible everywhere within its scope, unless a different
declarator declares an identifier of the same name in the same
namespace.
Linkage specifies whether or not identifiers declared in two separate
declarators belonging to the ordinary identifier namespace refer to the
same object or function. (There is a similar issue with respect to
structure and union tags, but that is dealt with specially and not
through linkage). There are three kinds of linkages: none, internal and
external. If the two declarators both specify identifiers with no
linkage, or they specify identifiers with differring linkage, they refer
to distinct objects or functions (One should keep in mind that extern
does not always specify external linkage). Same is obviously true if
the two identifiers are lexically different (with some exceptions).
However, if the two identifiers are lexically the same, and both have
internal linkage and both belong to the same translation unit, they
refer to the same object or function. Similarly, if the two identifiers
are lexically identical, and both have external linkage, they refer to
the same object or function, no matter where the declarations are. The
same translation unit is not allowed to have two lexically identical
identifiers one declared with internal and the other with external
linkage.
Duration refers to how long an object is valid. Objects of static
duration conceptually exist from just before the beginning of the
program to just after. Objects of automatic duration (which always have
block scope) exist as long as the innermost block surrounding its scope
is active or suspended due to to a function call (including
interrupts). Malloced objects exist from the malloc (or realloc) till
the free (which may be implicitly done by realloc).
---
Kaz Kylheku
wrote:
>Kaz Kylheku wrote:
>>
>> On Wed, 19 May 1999 10:37:53 -0400, Randy Yates <randy...@ericsson.com>
>> wrote:
>>
>> >this nut on usenet who thinks there's no such thing as global variables in
>> >C. Ha!
>>
>> to be ignorant of the subtleties of linkage, duration and scope. Not to
>> mention that they are unfamiliar with the documents that define the tools they
>> are using, which is just plain bad engineering.
>
>If a rogue software engineer had a gun to your head and said "tell
>me what a 'global C variable' is or I'll shoot," would you so arrogantly
>dismiss the usage as well? I'd bet some good money you wouldn't.
I'd probably just say whatever I think he wants to hear, but to be honest, I
have no idea what exactly a global C variable is, since the term isn't well
defined, and the classic definitions are rooted in simplistic languages like
Pascal, BASIC or 1960's Fortran. To say that some object is ``global'' in C is
perhaps to say that it has static duration and may be referenced with an
identifier that has external linkage. Should internal linkage be included too?
How about static objects whose definitions are in a statement block? Are those
global? What about this:
int *pglobal;
#define global (*pglobal)
void foo(void)
{
static int x;
pglobal = x;
}
The macro ``global'' behaves like a global variable, doesn't it. If
it walks like a duck and quacks like a duck... What about dynamic objects? If I
malloc something at the start of the program and then use it everywhere, surely
it is global! Or can only objects with identifier names be considered global?
What if a pointer to some auto object auto object declared in the main
function is passed into every module in a program? Is that local then
global? ;)
The problem with ``global'' is that in C, you have to consider how something is
used dynamically, not merely where its definition appears relative to the
program text.
>You like to sit in your ivory computer science towers and criticize
In times like this, the fortune file comes in handy:
"A word to the wise: a credentials dicksize war is usually a bad idea on
the net."
(David Parsons in c.o.l.development.system, about coding in C.)
I'm sitting in the trenches, trying to push a commerical middleware application
out the door. I find that language pedantry is an important contributor to
software quality in the real world.
Not everyone who believes in precise specifications and standards is an ivory
tower computer scientist. In fact, these things are more useful in real-world
development than in CS research. The computer scientist can just invent a
language and write programs in it using a HB pencil. (Really, is there
a more portable tool?)
>those who ask for help without offering any real assistance.
You were asking about terminology, so you got exactly what you were asking for.
Such questions call for pedantic precision. It's not clear what further
assistance you need, if any. There is the FAQ, of course, which has pointers
to reference materials.
>Some of you are somewhat helpful, but for the most part I have
>experienced arrogance here. That is sad because it means that
>I will look elsewhere for my answers.
The problem is that you just don't seem to believe the answers you got here and
want some kind of second opinion. If you ask enough experts, you can eventually
confirm any assertion about C or any other topic.
It so happens that in comp.lang.c, you will get the gospel according to
ANSI/ISO, and a staunch resistance against watering down complex abstractions
to fit naive preconceptions.
Kaz Kylheku
wrote:
>of information). My copy of "The annotated C standard" is certainly
>the tattiest book I have. :-)
You will have to translate ``tattiest'' for us non speakers of English.
Do you mean most tattered?
My handmedown old K&R2 came pre-tattered. It's better that way; you don't have
to spend the time yourself turning it into a status symbol. :)
Alex...@scitex.com
randy...@ericsson.com wrote:
> You like to sit in your ivory computer science towers and criticize
> those who ask for help without offering any real assistance.
> Some of you are somewhat helpful, but for the most part I have
> experienced arrogance here. That is sad because it means that
> I will look elsewhere for my answers.
A pity; you've received a lot of good and correct answers.
I suppose the problem here is more with your attitude - you were
prepared to receive an answer mor or less equal to your pre-defined
conception.
As for "ivory towers" - most of regulars here do earn their bucks
in the industry, not in the academy. But they prefer to use terminology
that is correct in C language definition scope :)
--
Regards,
Alex Krol
Disclaimer: I'm not speaking for Scitex Corporation Ltd
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
Will Rose
: Kaz Kylheku wrote:
:>
:> On Wed, 19 May 1999 10:37:53 -0400, Randy Yates <randy...@ericsson.com>
:> wrote:
:> >Thanks for the laugh, Jens! I'll now go proclaim to my colleagues that there's
:> >this nut on usenet who thinks there's no such thing as global variables in
:> >C. Ha!
:> There is no such *term* as ``global variable'' in C, and people who use it tend
:> to be ignorant of the subtleties of linkage, duration and scope. Not to
:> mention that they are unfamiliar with the documents that define the tools they
:> are using, which is just plain bad engineering.
: If a rogue software engineer had a gun to your head and said "tell
: me what a 'global C variable' is or I'll shoot," would you so arrogantly
: dismiss the usage as well? I'd bet some good money you wouldn't.
: You like to sit in your ivory computer science towers and criticize
: those who ask for help without offering any real assistance.
: Some of you are somewhat helpful, but for the most part I have
: experienced arrogance here. That is sad because it means that
: I will look elsewhere for my answers. Thank you, and have a
: nice day!
I think you're right, it would be best for everybody if you asked your
questions elsewhere. You've had a number of extremely clear and
helpful posts from some of the best C programmers in the world - I
thought I understood scope and linkage quite well myself until I
read Lawrence's post - and all you can do is complain that people
have criticized you (perish the very thought) and you've received
no real assistance. Best, as you say, for you to go (far) away.
Will Rose
: On Wed, 19 May 99 23:04:52 GMT, Lawrence Kirby <fr...@genesis.demon.co.uk>
: wrote:
:>of information). My copy of "The annotated C standard" is certainly
:>the tattiest book I have. :-)
: You will have to translate ``tattiest'' for us non speakers of English.
: Do you mean most tattered?
scruffiest, most dogeared, most thumbed. I think 'tat', junk or cheap
jewellery, may be a recent back-formation. My OED's at the cleaners, but
tat was a coarse canvas, and there's also tatty and tatting.
: My handmedown old K&R2 came pre-tattered. It's better that way; you don't have
: to spend the time yourself turning it into a status symbol. :)
I have a second career rescuing copies of K&R and Software Tools from
swap meets. I now have four copies of Software Tools in Pascal, none
of which I've read. (The copy I use is the original, in Ratfor).
Jens Schweikhardt
...
#> ISO 9899:1990 6.1.2.1 Scope of identifiers
#>
#> An identifier is visible (i.e. can be used) only within a region of
#> program or text called its /scope/. There are four kinds of scopes:
#> function, file, block and prototype. [...]
Randy:
#> # don't see how scope and linkage can be separated since they both deal with
#> # the "visibility of variables within a program."
#>
#> Please understand that they are different concepts.
# In the following code,
# #include <stdio.h>
# void foo (void);
#
# int main (void)
# {
# foo();
# return 0;
# }
# static int bar = 0;
# void foo(void)
# {
# printf ("%d\n", bar);
# }
# "bar" WILL NOT be visible to functions in other files. However, in
Yes, because you changed the linkage of bar to internal. Its scope
is still 'file'.
# #include <stdio.h>
# void foo (void);
#
# int main (void)
# {
# foo();
# return 0;
# }
# int bar = 0;
# void foo(void)
# {
# printf ("%d\n", bar);
# }
# "bar" WILL be visible to functions in other files.
Yes because its linkage is external. Its scope is still 'file'.
# Since the only difference is what you call linkage, then linkage
# affects visibility and therefore scope.
This is a strange conclusion. If the only difference is linkage,
then only linkage is different (which is a tautology). I think
you include into your definition of "visibility" the notion of
"what the linker can see to resolve symbols". That's different
from the visibility the Standard mentions in the cited paragraph.
#> Scope determines
#> where an identifier in one translation can be used (i.e. written to
#> refer to some entity).
# Where is this definition of scope found?
I quoted it from the International Standard for the C Programming language.
# Perhaps this is the entire
# problem, i.e., there are multiple definitions of scope. In my mind,
# scope refers to the visibility of variables.
...in a translation unit (not in the entire program, that's the difference!)
# Even if scope is defined the way you say, I still have the
# problem I outlined previously, i.e., how does one distinguish
# between variables that are visible only within a file and
# those visible to the entire program?
One has internal linkage, the other external linkage.
# What syntax would you
# use for these distinctions?
Use the static and extern keywords.
#> The difference of scope and linkage is obvious
#> for identifiers that don't *have* linkage (like labels, automatic
#> variables, structure tags, macro names etc). External and internal
#> Linkage only applies to functions and sometimes objects.
# What's an object? As far as I know, there are no objects in C.
ISO 9899:1990 3 Definitions and conventions
3.14 object:
A region of data storage in the execution environment, the contents
of which can represent values. Except fo bit-fields, objects are
composed of contiguous sequences of one or more bytes, the number,
order and encoding of which are einther explicitly specified or
implementation-defined. When referenced, an object may be interpreted
as having a particular type...
[loosely spoken, an object is a variable; but arrays of structs,
including optional struct padding are objects as well.]
#> Why do you refuse to communicate using terms defined as precise as
#> possible in an international standard, like "translation unit"?
# What's imprecise about "file?" When is a file not a translation unit?
A translation unit consists of the source file with all "#included" files
and less all lines skipped by conditional compilation. Again this is what
the C Standard says.
# We can call files
# "operating-system specific persistent information storage units"
# too, but while not use the simple 4-letter word "file?"
We can, but in the interest of precise communication we should use
the terms accepted in the C community. Here, what you call file
is called a source file, and what the compiler sees and translates
is a translation unit, i.e. an entity suitable for separate compilation.
It's obvious that this must inlcude all headers needed.
# My problem is that I am a thinking man, and if you want me to speak
# in terms that are more complex, you must demonstrate for me a good
# reason.
I hope that you accept "For most precise communication and getting
the point across" as a good reason :-)
# I have this attitude because I have seen many, many instances
# where a problem or situation was made intractable because of
# unnecessary complexity, thus I abhor it.
There's nothing wrong with making things simple. But as some genius
said many moons ago (Einstein?): "One must explain things as simple
as possible. But never simpler."
#> What is a global variable? There's no such thing in C.
# Thanks for the laugh, Jens! I'll now go proclaim to my colleagues that there's
# this nut on usenet who thinks there's no such thing as global variables in
# C. Ha!
Please do. I'm willing to defend my statement to my last drop of blood.
Anyone having read and understood C will come to the same conclusion.
The C Standard's Index doesn't have an entry for "global". (Depending on
ones arbitrary definition of "global" there may be global variables. I
think it's a useless definition. I speak of variables with file scope
and external linkage. That's all there is to say.)
Jens Schweikhardt
#> wrote:
#>
#> >Thanks for the laugh, Jens! I'll now go proclaim to my colleagues that there's
#> >this nut on usenet who thinks there's no such thing as global variables in
#> >C. Ha!
#>
#> There is no such *term* as ``global variable'' in C, and people who use it tend
#> to be ignorant of the subtleties of linkage, duration and scope. Not to
#> mention that they are unfamiliar with the documents that define the tools they
#> are using, which is just plain bad engineering.
# If a rogue software engineer had a gun to your head and said "tell
# me what a 'global C variable' is or I'll shoot," would you so arrogantly
# dismiss the usage as well? I'd bet some good money you wouldn't.
I'd ask that engineer one question: Do you want a correct answer
or do you want me to tell you what you want to hear? In the latter
case I had a strong doubt that that guy had the "engineer" title
acquired rightfully. It reminds me of when Galilei was asked whether
he still believes that the Earth revolved round the Sun.
Yes. I would die for "NO GLOBAL VARIABLES IN C!" I am an engineer.
I am a pysicist. There's no point in hiding the truth. Do you
want to be lied to?
# You like to sit in your ivory computer science towers and criticize
# those who ask for help without offering any real assistance.
Come on, we've been as helpful as we could be. Please note that
if I were in a bad mood (which I'm not) I could view your comments
on my explanations as offending. Still, I think you are an engineer
and want to learn about C and that you will appreciate the time I
take to explain some C concepts to you in excruciating detail and
backed by quotes from an International Standard.
# Some of you are somewhat helpful, but for the most part I have
# experienced arrogance here.
Maybe it's because laughing at "translation unit" or "no global
variables in C" shows some arrogance and ignorance as well?
# That is sad because it means that
# I will look elsewhere for my answers.
Well, there are other precise resources on C, like the FAQ, the
Standard itself, good books, WWW-Sites and whatnot. Maybe you
should try asking about scope and linkage in this groups moderated
brother (or sister? Do newsgroups have gender?). But in especially
for comp.lang.c.moderated, the answers will be identical to Kaz',
Lawrence's and mine. [Not only because we hang out there as well
to confuse newbies and old farts :-)]
Lawrence Kirby
k...@ashi.FootPrints.net "Kaz Kylheku" writes:
>On Wed, 19 May 99 23:04:52 GMT, Lawrence Kirby <fr...@genesis.demon.co.uk>
>wrote:
>>of information). My copy of "The annotated C standard" is certainly
>>the tattiest book I have. :-)
>
>You will have to translate ``tattiest'' for us non speakers of English.
>Do you mean most tattered?
Well, it isn't exactly tattered but the word is similar. From a Concise
OED
tatty: Ragged, untidy, shabby, tawdry.
And the following which are not exactly what I meant but obliquely applicable
nevertheless: fussily ornate, inferior
>My handmedown old K&R2 came pre-tattered. It's better that way; you don't have
>to spend the time yourself turning it into a status symbol. :)
Well, I seem to have been subject to the usual K&R musical chairs.
The copy of K&R1 I ended up with is certainly not the one I started with,
indeed it has the name of somebody in it I've never heard of. :-)
Richard Heathfield
<927208...@genesis.demon.co.uk>...
> In article <slrn7k73k...@ashi.FootPrints.net>
> k...@ashi.FootPrints.net "Kaz Kylheku" writes:
>
> >On Wed, 19 May 99 23:04:52 GMT, Lawrence Kirby
<fr...@genesis.demon.co.uk>
> >wrote:
> >>of information). My copy of "The annotated C standard" is certainly
> >>the tattiest book I have. :-)
> >
> >You will have to translate ``tattiest'' for us non speakers of English.
> >Do you mean most tattered?
>
> Well, it isn't exactly tattered but the word is similar. From a Concise
> OED
>
> tatty: Ragged, untidy, shabby, tawdry.
>
> And the following which are not exactly what I meant but obliquely
applicable
> nevertheless: fussily ornate, inferior
>
> >My handmedown old K&R2 came pre-tattered. It's better that way; you
don't have
> >to spend the time yourself turning it into a status symbol. :)
>
> Well, I seem to have been subject to the usual K&R musical chairs.
> The copy of K&R1 I ended up with is certainly not the one I started with,
> indeed it has the name of somebody in it I've never heard of. :-)
>
I'm sure it's been said before (by Kaz?) that the principal distribution
method of K&R is theft. Recently, I tried to buck this trend by
***buying*** my (second) copy of K&R2 when my first ("Draft-proposed")
started to look a bit tatty. Where did I get the first? No comment. :-)
Steve Thompson
> problem, i.e., there are multiple definitions of scope. In my mind,
> scope refers to the visibility of variables.
Scope:
The scope of a declaration is the region of the C program text
over which that declaration is active. In C, identifiers may
have one of six scopes...
Top-level identifiers
Extends from its declaration point to the end of the
source program file.
Formal parameters in functions and definitions
Extends from its declaration point to the end of the
function body.
Formal parameters in function prototypes
Extends from its declaration point to the end of the
prototype.
Block (local) identifiers
Extends from its declaration point to the end of the
block.
Statement labels
Encompasses the entire function body in which it
appears.
Preprocessor macros
Extends from the #define command that declares it
through the end of the source program file, or until
the first #undef command that cancels its
definition
Non preprocessor identifiers declared within a function or block
are often said to have block scope, or local scope. Identifiers
in prototypes have prototype scope. Statement labels have
function scope. All other identifiers have file scope.
Visibility:
A declaration of an identifier is visible in some context if a
use of the identifier in that context will be bound to the
declaration. That is, the identifier will be associated with
that declaration. A declaration must be visible throughout its
scope, but it may also be hidden by other declarations whose
scope and visibility overlap that of the first declaration.
C A reference manual. Harbison and Steele. P 67
>
> Even if scope is defined the way you say, I still have the
> problem I outlined previously, i.e., how does one distinguish
> between variables that are visible only within a file and
> those visible to the entire program? What syntax would you
> use for these distinctions?
>
> > The difference of scope and linkage is obvious
> > for identifiers that don't *have* linkage (like labels, automatic
> > variables, structure tags, macro names etc). External and internal
> > Linkage only applies to functions and sometimes objects.
>
> What's an object? As far as I know, there are no objects in C.
>
Object:
An object is a region of memory that can be examined and
stored into.
C A reference manual. Harbison and Steele. P 179
[snip]
>
> Thanks for the laugh, Jens! I'll now go proclaim to my colleagues that there's
> this nut on usenet who thinks there's no such thing as global variables in
> C. Ha!
And I will proclaim to my colleagues that there's this nut on usenet who
absolutly thinks that there are such things as global variables in C
even after its been explained to him by the best programmers in the
world
that there is no such thing.
If Lawrence Kirby says there is no such thing, you can bet your life on
it.
Best Wishes,
Steve
Steve Thompson
head with the definitions provided in Harbison and Steele. I meant no
mal intent by my previous post. I provided the definitions to give you a
clearer look at what the other posters were trying to tell you. If
*your* definition of "global", is a variable defined outside of any
function including main() which will be visible from any function in the
current translation unit, then, yes, there is such a thing. But, just to
point out to you, as others have done, this is not a "global" variable.
Its simply an "object" or variable, if you will, which has file scope.
I have found that, "C A Referenece Manual" by Harbison and Steele, has
been an invaluable resource. It's ISBN number is 0-13-326224-3 and its
put out Prentice Hall.
Steve
G.D.Thurman
> My handmedown old K&R2 came pre-tattered. It's better that way; you don't have
> to spend the time yourself turning it into a status symbol. :)
>
In my case, it is a K&R1. It is a classic. By the way, The Practice
of Programming by Kernighan and Pike is great!
G.D.Thurman, CS Instructor @ Scottsdale Community College
phone: 602.423.6110 fax: 602.423.6101
email: thur...@inficad.com
www: http://www.inficad.com/~thurmunit/index.shtml